home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 1793 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB

  1. Path: news.eunet.fi!fipnet!kone!jsaarinen
  2. Newsgroups: comp.sys.amiga.programmer
  3. X-NewsReader: IntuiNews 1.2b (31.7.94)
  4. References: <38231986@kone.fipnet.fi> <judas.0hi3@tomtec.abg.sub.org>
  5. From: "Jyrki Saarinen" <jsaarinen@kone.fipnet.fi>
  6. Date: Tue, 23 Jan 96 15:56:14 UT
  7. Comments: Illegal date header - new date added by quicknews
  8. X-Original-Date: Mon, 22 Jan 96 23:50:19 
  9. MIME-Version: 1.0
  10. Content-Type: text/plain; charset=iso-8859-1
  11. Content-Transfer-Encoding: binary
  12. Distribution: world
  13. Subject: Re: Serial Cable
  14. Message-ID: <38232131@kone.fipnet.fi>
  15.  
  16.  
  17. > On the ECS there a bit called BLTPRI, found in DMACON. Setting this bit
  18. > means to give the blitter priority over the CPU in case of chipram access.
  19. >
  20. > Making the blitter busy enough, makes any access to chipram from the CPU
  21. > delayed until the blitter has finished its operation.
  22.  
  23. This is the case even without BLTHOG bit turned on, chip ram
  24. memory bandwidth is lower when blitter is active. I have noticed
  25. it as are many others.
  26.  
  27. > As the BLitBusyBit was somehow buggy on prior chipsets, some programmers
  28. > found an other solution.
  29.  
  30. Why they did not read the few lines what HW Manual tells how
  31. to wait the blitter. Besides, that situation occurs really
  32. rarely.. 
  33.  
  34. ---cut---
  35.     Because of a bug in Agnus (prior to all revisions of fat Agnus)
  36.      this code may return too soon when the blitter has, in fact, not 
  37.     started the blit yet, even though BltSize has been written.  
  38.  
  39.     This most often occurs in a heavily loaded system with extended memory,
  40.     HIRES, and 4 bitplanes.
  41.  
  42.     WaitBlit currently tries to avoid this Agnus problem by testing
  43.     the BUSY bit multiple times to make sure the blitter has started.
  44.     If the blitter is BUSY at first check, this function busy waits.
  45.  
  46.     This initial hardware bug was fixed as of the first "Fat Agnus" chip, 
  47.     as used in all A500 and A2000 computers.
  48.  
  49.     Because of a different bug in Agnus (currently all revisions thru ECS)
  50.      this code may return too soon when the blitter has, in fact, not 
  51.     stopped the blit yet, even though blitter busy has been cleared.  
  52.  
  53.     This most often occurs in a heavily loaded system with extended memory,
  54.     in PRODUCTIVITY mode, and 2 bitplanes.
  55.  
  56.     WaitBlit currently tries to avoid this Agnus problem by testing
  57.     the BUSY bit multiple times to make sure the blitter has really
  58.     written its final word of destination data.
  59. ---cut--
  60.  
  61. > To go sure the blitter has finished, you just access chipram.
  62. > (naaaahh, don`t tell me about waitblit() .. =)
  63.  
  64. What? How the hell blitter state can be tested by accessing
  65. chipmem?
  66.  
  67. > As the AAchipset allows access to chipram, while blits are active, you
  68. > loose the syncronisation with the blitter.
  69. > (this also happens, when ECS-chipset is selected !!)
  70.  
  71. Are you actually saying that on A500/2000 one cant access
  72. chipram while blitting?
  73.  
  74. Syncronisation? Isnt it more like trashing the memory if blitter
  75. waiting fails?
  76.  
  77. I have always wondered why some people did no blitter waiting,
  78. instead they did delay loops! What a brilliant idea!
  79.  
  80. Instead of waiting the blitter correctly they decided to
  81. spend the same amount of time in a delayloop..
  82.  
  83. --                               _
  84. a Stellar programmer          _ //
  85. "Amiga - back for the future" \X/
  86.